I'm inclined to merge this, as the unit tests look sensible. The GODMODE mmapPorts is intriguing as well, I'm curious whether that will get me unstuck on #120 (comment)

I'll merge this by Monday unless @per1234 or @matthijskooijman see any dealbreakers in there.

I'm not sure if this is the best approach, but it's nothing that can't be improved on later, I think.

For completeness, I think there's also a similar macro to get at the port's direction register, that could maybe be added (or later, of course).

It's a bit memory-inefficient (allocating 1 byte per pin to store one bit), but that's not really an issue when running CI either.

One thing that I'm unsure about is the 256 extra pins being allocated as "padding". I'd say that pin numbers run from 0 to MOCK_PINS_COUNT or so, so why the extra 256? There's a comment, but I don't understand it (and haven't looked at the __MK20DX128__ that it references, not sure where to look).

For the padding, see https://github.com/arduino-libraries/Ethernet/blob/master/src/utility/w5100.h#L358.

I've removed the padding and limited the code to AVR only. Any other suggestions?

Responding to comments in #193, which are indeed better placed here.

That can certainly be done. As to the "else" portion, should I just leave them undefined since I'm not in a position to fully implement them for every architecture?

Yes, that's what I'd do for now. Things can be added for other architectures, but that requires careful review of what the relevent Arduino cores implement. Also, I'd expect that AVR is the most likely one to have sketches that use this semi-internal API, so this would cover most cases.

As for the padding and other boards, I'd think that supporting those particular code and Ethernet library, would be a separate thing (if it's really desirable at all).

From another quick glance, this looks ok to merge to me.

Thanks for the discussion on this!